Using Short Timer Intervals

Using Short Timer Intervals

Timer requests from processes that are not running under a nondegrading real-time priority are, in all systems, rounded up to the HZ interval.

A process running at a nondegrading, real-time priority (see "Setting a Nondegrading Real-Time Priority") can make use of an interval that is shorter than the HZ frequency (10 milliseconds). The actual interval that elapses is different in different versions of IRIX.

Fast Timers With a Clock Comparator

In systems with a clock comparator, the fasthz tuning parameter has no effect on timer requests. Timer requests from real-time processes are rounded only to the nearest hardware timer unit--21 nanoseconds in the Challenge/Onyx system.

Fast Timers Without a Clock Comparator

In uniprocessors and Crimson systems, the minimum effective timer resolution for real-time processes is set by the fasthz system tuning parameter. Any timer request is rounded up to the nearest multiple of the fasthz interval.

You can inspect and change the current value of fasthz using the systune command

# systune -i
Updates will be made to running system and /unix.install
systune-> fasthz
        fasthz = 1000 (0x3e8)
systune-> quit

The default value is 1000. That is, the minimum effective timer interval for a real-time process is 1 millisecond.

In systems that have no clock comparator, the kernel implements fast timers by shortening the periodic timer interval to the fasthz frequency whenever a process sets a timer at an interval that is not a multiple of HZ The frequent interrupts needed to support fast timers cause an overhead load of several percent of the power of one CPU. In these systems you should try to design your real-time application to use intervals that are multiples of 10 milliseconds, so that the fast interrupt rate is not needed. When that is not feasible, you can assign the interrupt to a particular CPU (see "Assigning the fasthz Processor").

Selecting the fasthz Value

You may need to experiment with different fasthz values in order to produce a repeatable, short interval. On a Challenge/Onyx system the hardware clock interval is 21 nanoseconds, which does not divide evenly into most fasthz intervals. The fast timer support code uses integer division, and it has some difficult problems with truncation.

For example, suppose you want to set an itimer to define a 60 Hz frame rate. You would set an itimer with a value of 16,667 microseconds.

Experience has shown that the default fasthz value of 1000 does not give good results with a 16.67 millisecond itimer. In IRIX version 5.2, this combination "jitters" on either side of the target interval. In version 5.3, itimers are guaranteed always to delay at least the specified time. While in 5.3 the interval is not shorter than 16.67 milliseconds, it is sometimes longer. Changing to a fasthz of 2400 (a multiple of the desired interval rate) does not solve the problem, which was due to integer truncation in the timer routine. However, a fasthz frequency slightly less than a multiple of the desired frame rate, 2390, does produce a dependable 16.7 millisecond interval.

Note: Itimers are not recommended as a way to schedule for a high frame rate. When designing a real-time program for a high frame rate the REACT/Pro Frame Scheduler offers a much more reliable and accurate way to schedule repetitive processes.

Which CPU Handles Timer Interrupts

Normally, interval timer interrupts are taken by the CPU in which the itimer was initialized. However, when you isolate a particular CPU (see "Isolating a CPU From TLB Interrupts"), all itimers pending for that CPU are retargeted to the assigned Clock CPU (see "Assigning the Clock Processor"). Any new itimer requests made in an isolated CPU after it has been isolated are taken on that CPU.

For a continuously-running real-time process, it is generally best to take interval timer interrupts on the CPU where the process runs. This helps to reduce the impact of timer handling on other CPUs, and helps to reduce the time to deliver the SIGALRM.

When timer interrupts are handled in any CPU, timer handling can temporarily be out of synchronization with the time-of-day service. There is a kernel tuning parameter, itimer_on_clkcpu, which if set forces all timer interrupts to be taken on the CPU that is the clock CPU. This parameter should only be set when it is crucial that all processes see an exact, consistent relationship between itimer intervals and time of day stamp values. Because it forces timer handling to a single CPU, it can increase the latency of SIGALRM delivery.